The design and development of an architecture for a business system typically begins with the definition of the goals and objectives of the business system.
A business system has a set of business goals and objectives to fulfill. The business system performs various business processes to fulfill these goals and objectives. The business process is an ordered series of events, which, among other things, manage the exchange of information from one or more sources to one or more destinations. Such sources and destinations may be internal, or external (e.g., customer, or partner applications), or both, and, in general, the business process is applied to control how the exchange of information is accomplished.
A large and complex business system performs multiple business processes across various geographical locations. A software implementation of such a business system automates these business processes for higher accuracy, efficiency and productivity. Accurate software implementation of such a business system requires the creation of the software architecture of the business system. The software architecture (also sometimes called architecture hereinafter) in this context is a specification that captures the structure and functionality of the software that implements the business system. The specification helps the various developers to understand and analyze different functional and quality of service aspects of the business system well before the software implementation of the business system.
Conventionally, the architecture description of a business system is captured using non-formal box and line diagrams with textual annotations. Such a description contains project and people specific idiosyncrasies. When the business system is very large and complex, it becomes extremely difficult for a reviewer to manually verify whether all of the requirements of the business system have been implemented in the architecture, and how each requirement has been implemented in the architecture, e.g., traceability of the requirements becomes very difficult. As a consequence, this informal box and diagram description approach often leads to ambiguity, misinterpretation and erroneous implementation when software developers implement the system from this description. This in turn, substantially increases the design and coding effort. As a result, higher productivity and development accuracy may not be achieved.
There have been many efforts from the researchers and practitioners of the art and science of architecture description to model various aspects of business architectures. Broadly there are two exemplary categories of languages recommended for architecture description, namely object oriented notations and languages such as the Universal Modeling Language (UML) and a class of Architecture Description Languages (ADL). There are a few prominent industry standards, such as 4+1 View, ISO RM-ODP 10746, Zachman framework, Institute of Electronics and Electrical Engineers (IEEE) 1471, that prescribe what an architecture should model. Though most ADLs are based on formal descriptions (which helps to verify and analyze the architecture models created using an ADL), there had been very little effort to standardize ADL. ADLs lack notations to capture the varying and comprehensive concepts of a business system such as the notion of architecture stakeholders, multiple views of a system, architecture rationale, and principles and so on. ISO RM-ODP prescribes a set of certain viewpoints required to describe the architecture at a very abstract level. ISO RM-ODP does not identify the views, architecture rationale and principles. Also, ISO RM-ODP does not describe how the architecture description may be handed off to a downstream development team for further implementation. The Zachman framework is subjective and not formal and has views that are generally not backed by notation.
While UML does allow some modeling of implementation details of an architecture, questions remain if UML 1.x is the right language for architecture description. For example, it has been argued that UML in its current form does not provide adequate support to describe an architecture as an interconnection of coarse grained components where it is possible to model hierarchical decomposition, various communication aspects, architecture styles, non-functional properties and where it is possible to perform a number of architectural analyses.
Accordingly, there is a need for an improved and standardized technique of modeling architecture for a business system.